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Abstract 


This document describes how Resource ReserVation Protocol (RSVP) 
PathErr messages may be used to trigger rerouting of Multi-Protocol 
Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point 
Traffic Engineering (TE) Label Switched Paths (LSPs) without first 
removing LSP state or resources. Such LSP rerouting may be desirable 
in a number of cases, including, for example, soft-preemption and 
graceful shutdown. This document describes the usage of existing 
Standards Track mechanisms to support LSP rerouting. In this case, 
it relies on mechanisms already defined as part of RSVP-TE and simply 
describes a sequence of actions to be executed. While existing 
protocol definitions can be used to support reroute applications, 
this document also defines a new reroute-specific error code to allow 
for the future definition of reroute-application-specific error 
values. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5710. 
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Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The Resource ReserVation Protocol (RSVP), see [RFC2205], has been 
extended to support the control of Traffic Engineering (TE) Label 
Switched Paths (LSPs) for both Multi-Protocol Label Switching (MPLS) 
and Generalized MPLS (GMPLS) in, respectively, [RFC3209] and 
[RFC3473]. In all cases, a PathErr message is used to report errors 
to nodes upstream of the error-detecting node. As defined in 
[RFC2205] and left unmodified by [RFC3209], PathErr messages "do not 
change path state in the nodes through which they pass". 
Notwithstanding this definition, PathErr messages are most commonly 
used to report errors during LSP establishment, i.e., the RSVP-TE 
processing that occurs prior to the ingress receiving a Resv message. 
(See [RFC5711] for a broader discussion on PathErr message handling.) 
Support for such usage was enhanced via the introduction of the 
Path_State_Removed flag in [RFC3473], which enables a processing node 
to free related LSP state and resources. The usage of PathErr 
messages during LSP establishment was further covered in [RFC4920], 
which describes in detail how a node may indicate that it or one of 
its associated resources should be avoided, i.e., routed around, 
during LSP establishment. 


PathErr messages can also be used to support a number of other cases 
that can occur after an LSP is established. This document focuses on 
the cases where PathErr messages can be used for a node to indicate 
that it desires an upstream node to reroute an LSP around the 
indicating node or resources associated with the indicating node. 
Some examples of such cases are soft-preemption and graceful shutdown 
(see [RFC5712] and [GRACEFUL]). 


This document uses the terminology "reroute request" to refer to the 
indication by a node that an upstream reroute should take place. 
This document describes how a node can initiate a reroute request 
without disrupting LSP data traffic or, when so desired, with the 
disruption of data traffic and removal of LSP-associated state and 
resources. The applicability of this document is limited to point- 
to-point LSPs. Support for point-to-multipoint LSPs are for further 
study. 


The mechanisms used to indicate reroute requests are derived from the 
mechanisms described in [RFC4920] and the error codes defined in 
[RFC4736]. This document describes (1) how a non-disruptive reroute 
request may be issued and, (2) based on an optional "timeout" period, 
how rerouting may be forced by removing LSP state and associated 
resources and signaling such removal. While this document describes 
how existing protocol definitions can be used to support rerouting, 
it also defines a new reroute-specific error code to allow for the 
future definition of reroute-application-specific error values. 
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1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Reroute Requests 


This section describes how a downstream node can indicate that it 
desires a node upstream (along the LSP path) to initiate the 
rerouting of an LSP, and how the upstream nodes can respond to such a 
request. Initiating nodes, transit nodes, and ingress nodes are 
described separately. 


2.1. Processing at Requesting Node 


When a transit or egress node desires to request the rerouting of an 
established LSP, it first determines if it can act on the reroute 
request locally. Such a check MUST be performed on the condition 
that the Explicit Route Object (ERO), see [RFC3209], received in the 
LSP’s incoming Path message does not preclude LSP rerouting. 
Examples of requests that may trigger reroutes are avoiding an 
outgoing interface, a component, label resource, or a next hop not 
explicitly listed in the ERO. In all cases, the actual repair action 
SHOULD be performed after verification that the local policy allows 
local repair for that LSP/state. That is, any traffic-rerouting 
action (associated to this state) must be initiated and completed 
only as allowed by local node policy. 


When the node cannot act locally, it MUST issue a PathErr message 
indicating its inability to perform local rerouting. The PathErr 
message MUST contain an ERROR_SPEC object of the format defined in 
[RFC2205] or [RFC3473]. Such a message MUST include one of the 
following combinations of error codes and error values: 


1. "Notify/Local node maintenance required" to support backwards 
compatibility and to reroute around the local node. 


2. "Notify/Local link maintenance required" to support backwards 
compatibility and to reroute around a local interface. 


3. "Reroute/<any Reroute error value>" for future compatibility 
and when backwards compatibility is not a concern. 
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The rest of the ERROR SPEC object is constructed based on the local 
rerouting decision and the resource that is to be avoided by an 
upstream node. It is important to note that the address and TLVs 
carried by the ERROR_SPEC object identify the resource to be avoided 
and not the error code and value. 


When the reroute decision redirects traffic around the local node, 
the local node MUST be indicated in the ERROR_SPEC object. 
Otherwise, i.e., when the reroute decision does not redirect traffic 
around the local node, the impacted interface MUST be indicated in 
the ERROR_SPEC object and the IF_ID [RFC3473] ERROR_SPEC object 
formats SHOULD be used to indicate the impacted interface. 


The IF_ID [RFC3473] ERROR_SPEC object format MUST be used to indicate 
a reroute request that is more specific than an interface. The TLVs 
defined in [RFC3471], as updated by [RFC3477], [RFC4201], and 
[RFC4920] MAY be used to provide specific, additional reroute request 
information, e.g., reroute around a specific label. The principles 
related to ERROR_SPEC object construction, defined in Section 6.3.1 
of [RFC4920], SHOULD be followed. 


2.1.1. Reroute Request Timeouts 


Reroute request timeouts are used to remove an LSP when there is no 
response to a reroute request. A reroute request timeout is used 
when an LSP is to be removed at the expiration of the reroute request 
timeout period. When such LSP removal is desired, and after 
initiating a reroute request, the initiating node MUST initiate a 
timeout during which it expects to receive a response to the reroute 
request. Valid responses are a PathTear message or a trigger Path 
message with an ERO, avoiding the resource that was indicated in the 
reroute request. If either type of message is received, the timeout 
period MUST be canceled and no further action is needed. Note, 
normal refresh processing is not modified by the introduction of 
reroute request timeouts. Such processing may result in Path state 
being removed during the timeout period, in which case the timeout 
period MUST also be canceled. 


If the reroute request timeout is reached, the initiating node MUST 
remove the LSP and its associated state and resources. Removal of 
LSP state is indicated downstream via a corresponding PathTear 
message. Removal is indicated upstream via a PathErr message with 
the error code of "Service preempted". The Path_State_Removed flag 
MUST be set if supported. When the Path_State_Removed flag is not 
supported, a corresponding ResvTear MUST also be sent. 
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2.2. Processing at Upstream Node 


When a transit node’s policy permits it to support reroute request 
processing and local repair, the node MUST examine incoming PathErr 
messages to see it the node can perform a requested reroute. A 
reroute request is indicated in a received PathErr message, which 
carries one of the error code and value combinations listed above in 
Section 2.1. Note that a conformant implementation MUST check for 
any of the three combinations listed in Section 2.1. 


A transit node MAY act on a reroute request locally when the ERO 
received in the LSP’s incoming Path message does not preclude the 
reroute. As before, examples include loosely routed LSP next hops. 
When the reroute request can be processed locally, standard, local 
repair processing MUST be followed. The node SHOULD limit the number 
of local repair attempts. Again, the expected norm is for local 
repair, and thereby this case, to be precluded due to policy. 


When the transit node supports [RFC4920] and is a boundary node, and 
Boundary rerouting is allowed, it SHOULD use a route request as a 


trigger to reroute the LSP. (Per [RFC4920], the Flags field of the 
LSP_ATTRIBUTES object of the initial Path message indicates "Boundary 
rerouting".) In the case the node triggers rerouting, it first MUST 


identify an alternate path within the domain. When such a path is 
available, the node MUST terminate the PathErr message and issue a 
Path message reflecting the identified alternate path. Processing 
then continues per [RFC4920]. When an alternate path is not 
available, the node cannot act on the reroute request. 


When a transit node cannot act on a reroute request locally, per 
standard processing, it MUST propagate the received PathErr message 
to the previous hop. 


2.3. Processing at Ingress 


When reroute processing is supported, an ingress node MUST check 
received PathErr messages to identify them as indicating reroute 
requests. A reroute request is indicated in a received PathErr 
message, which carries one of the error code and value combinations 
listed above in Section 2.1. Note that a conformant implementation 
MUST check for any of the three combinations listed in Section 2.1. 


Upon receiving a reroute request, the ingress MUST attempt to 
identify an alternate path, avoiding the node, interface, resource, 
etc. identified within the ERROR_SPEC object. When an alternate path 
cannot be identified, the reroute request MUST be discarded. When an 
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SE 


alternate path is identified, a corresponding make-before-break LSP 
SHOULD be initiated and standard make-before-break procedures MUST be 
followed. 


Example Reroute Requests 


This section provides example reroute requests. This section is 
informative rather than prescriptive. Reroute requests are always 
sent via PathErr messages. As described above, a PathErr message may 
contain either an [RFC2205] format ERROR_SPEC object, or an IF_ID 
[RFC3473] format ERROR_SPEC object; it is the address and TLVs 
carried by the ERROR_SPEC object, and not the error value, that 
indicates the resource that is to be avoided by the reroute. 


1. Node Reroute Request 
To indicate that the node should be avoided by an upstream node, the 


node originating the reroute may format the ERROR_SPEC per [RFC2205], 
for example: 


O IPv4 ERROR SPEC object: Class = 6, C-Type = 1 
4+------------- 4+------------- +------------- 4+------------- + 
| IPv4 Error Node Address (4 bytes) 
4+------------- 4+------------- +------------- +------------- + 
| Flags Error Code | Error Value 
4+------------- 4+------------- 4+------------- 4+------------- + 
The node address is set to the local node’s TE router address. Error 


code is set to either "Notify/Local node maintenance required" or 
"Reroute/<any Reroute error value>". 


.2. Interface Reroute Request 


To indicate that a numbered interface should be avoided by an 
upstream node, the node originating the reroute may format the 
ERROR_SPEC per [RFC3473], for example: 
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0 pi 2 3 
0123456789012345678°9012345678<9021 
BL A D En Es D D D D D D D D Rs D es D ee D ee D D D D 

| Length | Class-Num (6) | C-Type (3) 

BL Es D A Es D D D D D D ++ 
| IPv4 Error Node Address 
+-+-+-+-+-+-+-+-+-+-+-+- +++ 


| Flags | Error Code | Error Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type (1) | Length (8) | 


SE A D D Se M D Se A D ss D D ss ns D ne ts D © 
| IP Address | 
Foto toto D titan ta tata ta tata Se ss D D ns ns ns D SD = 


The node address is set to the local node’s TE router address. Error 
code is set to either "Notify/Local link maintenance required" or 
"Reroute/<any Reroute error value>". IP address is set to the TE 


address of the interface to be avoided. 
3.3. Component Reroute Request 


To indicate that an unnumbered component should be avoided by an 
upstream node, the node originating the reroute formats the 
ERROR_SPEC per [RFC4201], for example: 


0 1 2 3 
Or. 2 34 576: 78 9 O12 3 4 5:67 8. 920° TD 23.45. 6. 4 89 À 
SE ES ES ES D D SE SE A SE SE SE SE SE SE SE SR SE SE SE SEE SE SR SE SE SE SE SE SE 

| Length | Class-Num (6) | C-Type (3) 
SES SE ES SE SE SE A SO SE D SE SE SE SE SE SE SE SE SE SE SR SE SE SE SE SE SE 
| IPv4 Error Node Address 

Foto toto tai toto tito titi SO SE SE SE SE SE SE SE SE SE SE SE SR SE SE SE SE SE SE 
| Flags | Error Code | Error Value 

ES ES ES SE Su SE SE SE A SE SO SE SE SE SE SE SE SE SE SE SE SE SR SE SE SE SE SE SE 
| Type (3) | Length (12) 
ES ES EE ES SE SE SE A SE SO SE SE SE SE SE SE SE SO SE SRE SE SR SE SE SE SE SE Se 
| Router ID | 
Foto titi tai toto titi SE D A SE SE SE SE SE SE SE SE SE SO SE SE SE SR SE SE SR SE SE SE 
| Interface ID (32 bits) 

ES SES SE SE SE SE A SE SE SE SE SE SE SE SE SE SE SE SE SE SR SE SE SE SE SE SE 


The node address is set to the local TE address used in the 
advertisement of the bundle associated with the component. Error 
code is set to either "Notify/Local link maintenance required" or 
"Reroute/<any Reroute error value>". Router ID is set to the local 
router ID, and Interface ID is the identifier assigned to the 
component link by the local node. 
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4. 


Label Reroute Request 


To indicate that a label should be avoided by an upstream node, th 
node originating the reroute may format the ERROR SPEC per [RFC492 
for example: 


0 1 2 3 
012345678°9012345 6789012345678 90 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Length | Class-Num (6) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| IPv4 Error Node Address 
SAS ES SE DS SE SE SO A SO SE SE SE SE SE SE SE SE SO SE SE SE SE SE SRE SE SE 2 
| Flags | Error Code | Error Value 
Foto to tatoo toto titi SO SE M titi tata ta tata tata tatatitatatatet 
| Type (1) | Length (8) 
Foto to SAS ES D SE SE SR SO A M SE SE SO SE SE SE SE SE SE SE SRE SE SE SE SRE SE SE 
| IP Address 
ES ES AS ES A SE Su SE SO A M SE SE SE SE SE SE SE SE SE SE SE SE SR SE SR SE Su 
| Type (6) | Length (8) 
ES ES SE D SE titi titi M SE SE SO SE SE SE SE SE SE SE SE SE SR SE SRE SE SE 
| DOWNSTREAM LABEL 
foto toto toto tata tata tata tata tata ti SE SE SE SE SE SE SE SE SRE SE SE 


The node address is set to the local node’s TE router address. Er 
code is set to either "Notify/Local link maintenance required" or 
"Reroute/<any Reroute error value>". IP address is set to the TE 
address of the interface that supports the label to be avoided. 
DOWNSTREAM LABEL indicates the label to be avoided. 

IANA Considerations 


IANA assigned values for namespaces defined in this document and 
reviewed in this section. 


IANA made the assignment in the "Error Codes and Globally-Defined 
Error Value Sub-Codes" section of the "RSVP Parameters" registry: 


34 Reroute [RFC5710] 
This error code has the following defined Error Value sub-code: 
0 = Generic LSP reroute request 


Reroute error values should be allocated based on the following 
allocation policy as defined in [RFC5226]. 
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6. 


6. 


Range Registration Procedures 
0-32767 IETF Consensus 
32768-65535 Private Use 


Security Considerations 


Sections 9 of [RFC4920] and [RFC4736] should be used as the starting 
point for reviewing the security considerations related to the 
formats and mechanisms discussed in this document. This document 
introduces a new error code, but this code is functionally equivalent 
to existing semantics, in particular, the error code/error value 
combinations of "Notify/Local node maintenance required" and 


"Notify/Local link maintenance required". As such, this document 
introduces no new security considerations beyond what already applies 
to these existing formats and mechanisms. Future documents may 


define new error values; any considerations specific to those values 
should be discussed in the document defining them. 
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